1. Field of the Invention
This invention relates generally to communications, and, more particularly, to methodologies and concomitant circuitry for coalescing intelligence with communications in a switching node.
2. Description of the Background
Historically, a public telecommunications service was generally supported by a geographically-dispersed, circuit-switched network composed of a cascade of communication paths and switches having stored but static programs (called "generic" programs) for switching the communication paths to thereby establish an end-to-end connection--the essential function of the paths and switches was that of merely establishing this end-to-end connection.
Recently, services have been made "intelligent" in the sense that establishing a service is more than merely establishing a connection via the cascade of paths and switches. Such services have been achieved by associating intelligence with the switches. To exemplify one service, consider a customer placing a telephone call that requires special handling, such as a toll-free call (800 service). The call is intercepted by a local switching system which launches a query through a signaling network to a centralized database located in a centralized processor. The database, in turn, retrieves the necessary information to handle the call, and performs a number translation to map the "logical" 800 number to a "physical" routing number. The physical routing information is returned through the signaling network to the local switching system so that the call can be completed.
Even more recently, the notion of "active networking" has been introduced; active networking is intended to effect an even more significant change on the historical network paradigm, namely, a change from a passive carrier of analog/digital signals to a more general computational ability associated with network components, especially the switches. However, such efforts to this point in time have been devoted more to outlining the benefits that such a paradigm could achieve, without elucidating specifics of such an approach except in a few special cases.
For example, the paper entitled "On Active Networking and Congestion" as authored by Bhattacharjee, Calvert, and Zegura (BCZ) in January, 1996 and published as Georgia Institute of Technology Technical report GIT-CC-96/02, focuses on applying active networking concepts to handling network congestion. In BCZ, the model of what happens when a packet arrives at a node (used interchangeably with switch) is as follows--for the sake discussion, a packet is composed of a header part and a payload part:
(1) The output destination port for the packet is computed as usual. PA1 (2) If a packet contains a valid Active Processing Function Identifier (ACPI), it is sent to an active processor and processing continues; otherwise, it is transmitted as usual. PA1 (3) The function specified in the ACPI is computed, using the packet's association descriptor and user data as inputs. PA1 (4) If the result of the function is transformed data (e.g., reduced length), the packet's network-level header and ACPI are recomputed as necessary; the node's state is updated as required by the specified function. PA1 (5) The (possibly modified) packet is transmitted to its next-hop node.
It is extremely important to reiterate that the above procedure requires an Active Processing Function Identifier (ACPI) to differentiate between conventional processing and additional, that is, active processing. As BCZ further point out, the obvious place to put the ACPI is in the same header used to switch the packet. However, BCZ concludes that such an approach is unacceptable for at least two reasons. First, the approach does not work for ATM or any other technology where the switched unit is too small to accommodate additional overhead of the ACPI. And second, the approach is not backward-compatible, requiring that all network protocols become "active-aware". BCZ proposes that an alternative to placing the ACPI in the network header itself is to define a "generic" location for the ACPI function, sufficiently high in the protocol stack that the additional processing overhead is not prohibitive, but sufficiently low in the protocol stack to allow its location by switching nodes without too much knowledge of higher-level protocols. Thus, BCZ immediately rules out the use of the packet itself for differentiating between conventional and active processing. However, use of the packet (either the header, payload, or both) overcomes what BCZ deems to be unacceptable, that is, use of the packet itself eliminates additional packet overhead, and network protocols need not be "active-aware".
Moreover, the prior art is devoid of teachings or suggestions related to program execution in the switch based upon the following actions/events (an event triggers an action which, in turn, generates a desired response): the state of the program itself; the state of resources composing the switch; external control inputs serving the switch; other programs executing in the switch; data (packets) received over other ports of the switch; or combinations of these actions/events. In addition, there is no teaching or suggestion in the prior art wherein a new program can be downloaded to the switch, and then this new program can be executed, in conjunction with other stored programs if necessary, based upon data incoming to a port as well as any or all the foregoing actions/events. Finally, the prior art lacks any teachings or suggestions for executing a "guard" program, either stored or downloaded, to control execution of "guarded" programs to thereby preclude inconsistent configurations of the switch.